Flow-directed collaborative communication

ABSTRACT

Resolving a query received from a first node in a network includes accepting, by a second node in the network, ownership of the query from the first node, receiving, at the second node, an identification of a third node in the network, wherein the identification is received from a user of the second node and the user of the second node believes that a user of the third node has information necessary to resolve at least part of the query, and transferring, by the second node, ownership of the at least part of the query to the third node, wherein the accepting, the receiving, and the transferring dynamically generates a data structure that traces a propagation of the query, and the data structure is accessible to an origin of the query.

CROSS REFERENCE TO RELATES APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.13/795,063, filed Mar. 12, 2013, which is herein incorporated byreference in its entirety.

BACKGROUND OF THE INVENTION

The present invention relates generally to collaborative communications,and relates more particularly to flow-directed processes forcollaborative communications.

The growing complexity of the modern global business market introducesnew challenges to gathering information and solving problems. Criticalbusiness decisions often rely on collaboration across broad networks ofindividuals (e.g., coworkers, customers, vendors, business partners,etc.) who provide information and answers for individual pieces ofknowledge that help answer broader questions. The more complex thebusiness, the more collaboration may be necessary to answer a question.Delays introduced by differing time zones may introduce furtherchallenges still in networks that are truly globally integrated.

One conventional solution for rapidly responding to a business need isto organize a meeting (e.g., a teleconference) between the individualswhose input is required. Meetings provide an opportunity for immediateanswers to questions and decision making, provided that the right peopleare involved. However, it may be difficult to ensure that the rightpeople are involved if one does not first know what questions to ask inorder to obtain the required information. Moreover, meetingeffectiveness also relies on the individuals organizing the meeting toprovide a well-defined agenda and to take detailed records.

Another conventional solution for rapidly responding to business needsis electronic mail (“email”). Email allows the primary stakeholder toreach a larger audience more quickly that a meeting, and with lessinvestment of resources (and thus less potential waste). Email alsoleverages the collective knowledge base, allowing questions to beforwarded to additional individuals who are believed to have theanswers. However, since email tends to create an open loop, an answerwithin a required time frame is not guaranteed (time zone differencesmay also contribute to this drawback). Moreover, copying and forwardingof email can create divergent threads, making it difficult toreconstruct the history of the original query.

SUMMARY OF THE INVENTION

Resolving a query received from a first node in a network includesaccepting, by a second node in the network, ownership of the query fromthe first node, receiving, at the second node, an identification of athird node in the network, wherein the identification is received from auser of the second node and the user of the second node believes that auser of the third node has information necessary to resolve at leastpart of the query, and transferring, by the second node, ownership ofthe at least part of the query to the third node, wherein the accepting,the receiving, and the transferring dynamically generates a datastructure that traces a propagation of the query, and the data structureis accessible to an origin of the query. For simplicity's sake, theabove description makes reference to three nodes to illustrate theconcepts of the present invention; however, it will be appreciated thatthe above-described method may be performed using any number of nodes(including less than three nodes, and more than three nodes), as will beclear from the more detailed description that follows.

BRIEF DESCRIPTION OF THE DRAWINGS

So that the manner in which the above recited features of the presentinvention can be understood in detail, a more particular description ofthe invention may be had by reference to embodiments, some of which areillustrated in the appended drawings. It is to be noted, however, thatthe appended drawings illustrate only typical embodiments of thisinvention and are therefore not to be considered limiting of its scope,for the invention may admit to other equally effective embodiments.

FIG. 1 is a schematic diagram illustrating a portion of an exemplarynetwork within which embodiments of the present invention may bedeployed;

FIG. 2 is a flow diagram illustrating one embodiment of a method forresolving a query, according to the present invention; and

FIG. 3 is a high-level block diagram of query resolution method that isimplemented using a general purpose computing device.

DETAILED DESCRIPTION

In one embodiment, the present invention is a method and apparatus forflow-directed collaborative communication. Embodiments of the inventionprovide solutions (e.g., answers) to queries effectively and efficientlythrough a controlled series of ownership transfers. Within the contextof the present invention, “ownership” of a query (or a response) impliesa responsibility for delivery of information. In the event of a problem,this allows the path of the query (or response) to be traced back to asingle “owner” at any time.

In particular, the process begins with a base query (e.g., a question ora need), and a workflow is naturally generated with minimal effort,resulting in a highly efficient data stream feeding back to the primarystakeholder (e.g., the query's origin). The speed at which informationis provided is maximized, while the work required by any single personin the process is minimized, thereby overcoming barriers oforganizational boundaries, time zones, and accessibility.

FIG. 1 is a schematic diagram illustrating a portion of an exemplarynetwork within which embodiments of the present invention may bedeployed. In particular, the portion of the network represents a subsetof the network that is involved in responding to a query. Asillustrated, the portion of the network comprises a plurality of nodes102 ₁-102 _(n) (hereinafter collectively referred to as “nodes 102,”each of which represents a human user (hereinafter, “user” and “node”are used interchangeably to refer to the human user associated with anode). For example, each user may be an employee of a common businessentity. The network may comprise additional nodes that are not picturedor do not participate in responding to the query. Any of the nodes 102may communicate with other nodes 102 in the network (e.g., via email,personal messaging, or the like); communicative links between nodes areindicated by solid and dashed lines in FIG. 1, and explained in furtherdetail below in connection with FIG. 2. Thus, the nodes 102 and theconnections between the nodes 102 collectively form a data structure,such as a tree 100. The tree 100 defines a hierarchy in which the nodes102 in the lower levels of the hierarchy are descendants (e.g.,children) of nodes in the higher levels (e.g., parents). The hierarchymerely illustrates the propagation of the query and associated responsefrom user to user and does not necessarily indicate any other relationbetween the users (e.g., roles in a business entity or the like).

According to embodiments of the present invention, the users representedby the nodes 102 may collaborate in order to form a solution to a queryposed by one of the users. As described in further detail below, queriespropagate down the tree 100 from originating nodes to one or more nodeswho can respond to at least a portion of the query, and responses to thequeries propagate upward from the responding nodes back to theoriginating nodes. Ownership of the queries and responses is transferredas they are forwarded from node to node. Thus, the structure of the tree100 evolves dynamically as ownership of queries and responses istransferred.

FIG. 2 is a flow diagram illustrating one embodiment of a method 200 forresolving a query, according to the present invention. The method 200may be implemented, for example, at any of the nodes 102 illustrated inFIG. 1. As such, reference is made in the discussion of the method 200to various elements of FIG. 1. However, the method 200 is not limited bythe network configuration illustrated in FIG. 1, which is onlyexemplary. Progression of the method 200 results in a tree such as thetree 100 illustrated in FIG. 1. For ease of explanation, it is assumedthat at least the beginnings of the tree 100 (e.g., including a firstnode 102 ₁ and at least one level of descendant nodes such as the secondand third nodes 102 ₂ and 102 ₃, respectively) have been established atthe time that a node 102 invokes the method 200. Thus, the method 200describes the process of resolving a query from the perspective of anintermediate node 102 that is neither the origin nor the finaldestination of the query.

The method 200 begins in step 202. In step 204, the second node 102receives a query. For the purposes of illustration, it is assumed thatthe node 102 ₂ of FIG. 1 is the second node in step 204, although othernodes 102 (e.g., third node 102 ₃) may also receive the same query atsubstantially the same time and perform similar responsive operations tothose discussed below. The query originates with an originating node. Inthe example illustrated in FIG. 1, the first node 102 ₁ is theoriginating node; however, this does not necessarily have to be thecase. For instance, the first node 102 ₁ may be an intermediate nodelocated between the originating node and the second node 102 ₂ in thetree 100. The user of the originating node may be referred to as the“primary stakeholder” of the query, since it is assumed that he (or she)is the individual who requires the information requested by the query.

The query identifies information that the primary stakeholder is seeking(e.g., an answer to a question). The query may also specify additionalinformation, such as a deadline by which a response is required or anyrestrictions (e.g., confidentiality) associated with the requestedinformation. Furthermore, the query may constrain the form of anyresponse provided (e.g., if the query requests a date, a date may be theonly type of response that is permitted). It is noted that the queryreceived by the second node 102 ₂ in step 204 may not be identical tothe original query sent by the originating node, particularly if thefirst node 102 ₁ is not the originating node. For example, the queryreceived by the second node 102 ₂ may be a sub-query of the originalquery (e.g., seeking only a portion of the information sought by theoriginal query). Alternatively, the first node 102 ₁ may not alter thequery at all before forwarding the query to the second node 102 ₂ (e.g.,the first node 102 ₁ may believe that the second node 102 ₂ will be ableto respond to the query in its entirety). Receipt of the query by thesecond node 102 ₂ transfers ownership of the query from the first node102 ₁ to the second node 102 ₂. Thus, the user of the second node 102 ₂becomes a “secondary stakeholder” upon receiving ownership of the query.Transfer of ownership may be implied by receipt (e.g., automatic) or mayrequire explicit acceptance by the node 102 to which ownership is beingtransferred.

In step 206, the user at the second node 102 ₂ determines whether he iscapable of responding to the query. If the user determines that he iscapable of responding to the query, then the method 200 proceeds to step208. In step 208, the second node 102 ₂ (under the direction of theuser) supplies a response to the first node 102 ₁. The response mayoptionally include supporting documentation. In one embodiment, if theuser of the second node 102 ₂ is capable of responding to the query, butis not able to do so immediately (e.g., he may need time to assembleand/or verify information), he may first provide the first node 102 ₁with an estimated deadline by which he expects to respond beforeproviding the actual response. In this case, the deadline provided bythe user of the second node 102 ₂, as well as any deadlines by which anydescendant nodes intend to provide information to the second node 102 ₂,must sum together to satisfy any deadline specified by the originatingnode.

Alternatively, if the user of the second node 102 ₂ determines that heis not capable of responding to the query (e.g., he needs moreinformation), then the method 200 proceeds to step 210. In step 210, theuser of the second node 102 ₂ identifies at least one other user in thenetwork whose input may be required to respond to the query.

In step 212, the second node 102 ₂ adds, for each user identified instep 210, a new node 102 in the tree 100. In the example illustrated inFIG. 1, for example, the second node 102 ₂ adds a fourth node 102 ₄ anda fifth node 102 ₅. Each new node 102 is associated with a specific userand a specific query (or “sub-query”) for the specific user. Thesub-query is associated with the query received by the receiving node102 ₂ in step 204; however, the sub-query may seek only a portion of theinformation sought by the query received in step 204. In this way, theuser of the second node 102 ₂ may direct different portions of the queryto different users who may have different information and/or expertise,rather than count on the possibility that a single user can respond tothe entire query. Each sub-query is subject to any provisions imposed onthe original query (and any intervening sub-queries) by the nodes 102that the original query has traversed to this point (e.g., pertaining todeadline, confidentiality, or the like). Each sub-query is also subjectto any additional provisions imposed by the second node 102 ₂.

In step 214, the second node 102 ₂ sends a message to each of the usersfor whom a new node has been created. In one embodiment, the message issent automatically upon addition of the new nodes, as part of themechanism of the method 200 (e.g., as opposed to requiring some explicitaction on the part of the user of the second node 102 ₂). The messageincludes the specific query associated with the specific user of thenode to which the message is sent. Thus, ownership of the sub-queries istransferred from the second node 102 ₂ to the new nodes that have beencreated.

In step 216, the second node 102 ₂ receives responses back from at leastsome of the users to whom the messages were sent in step 214. Asdiscussed above, the second node 102 ₂ may receive estimated deadlinesby which responses can be expected before actual responses are received.In one embodiment, one or more of the responses may include supportingdocumentation. In one embodiment, a response may comprise an aggregationof responses provided by nodes 102 that are even further down in thehierarchy of the tree 100. In this case, the node from whom the secondnode 102 ₂ receives the response may have received and processedresponses to its own sub-queries that it created and sent (e.g., similarto steps 212-214). Ownership of the responses to the sub-queries istransferred from the responding nodes 102 to the second node 102 ₂ instep 216. As the ownership is transferred, the responding nodes 102close (i.e., become inactive in the tree 100).

In optional step 218 (illustrated in phantom), the user of the secondnode 102 ₂ processes the received responses. For instance, the responsesmay need to be reviewed and/or aggregated by the second node 102 ₂ inorder to form a proper response to the query received in step 204. In analternative embodiment, the sub-queries created by the second node 102 ₂may specify that the responses bypass the second node 102 ₂ and bedelivered directly to the first node 102 ₁.

The method 200 then proceeds to step 208, in which the second node 102 ₂delivers a response to the first node 102 ₁ as described above.Ownership of the response is transferred from the second node 102 ₂ tothe first node 102 ₁ in step 208. As the ownership is transferred, thesecond node 102 ₂ closes. Depending on how many other nodes the firstnode 102 ₁ sent the query to, the first node 102 ₁ may process anyresponses it receives in a manner similar to that described inconnection with step 218.

The method 200 ends in step 220, at least with respect to the secondnode 102 ₂. For any nodes 102 located in higher levels of the hierarchy(such as the first node 102 ₁), certain steps of the method 200 maycontinue (e.g., receiving, processing, and/or delivering responses),until the originating node has received a response to the originalquery.

Thus, the user of the originating node does not need to know who iscapable of responding to the original query; he need only know the nextperson to whom to send the query to facilitate the response (e.g., aperson with direct or indirect access to the information needed forresponse). Each person to whom the query (e.g., the original query or asub-query of the original query) is forwarded creates the next portionof the workflow that is required to generate the response. The user ofthe originating node is constantly aware of the extent of the tree thatis being created, of the time frame within which a response is expected,and whether part of the query may have stalled at an unresponsive user.The user of the originating node may modify the tree at any time (e.g.,by pruning portions of the structure that are not critical or likely tolead to unacceptable delays, by overriding requested deadlines, or thelike).

In one embodiment, queries and responses that are propagated inaccordance with the method 200 are sent and delivered through a centralserver. Thus, the central server tracks and maintains the progress ofthe original query (and any associated sub-queries) and the developmentof the tree. This progress and development may be viewable on, forexample, a web page that is hosted by the server. In one embodiment,access to the web page is controlled by the nodes 102 that the originalquery traverses. For example, the originating node may limit to whom itsoriginal query (and/or the response to the original query) is visible.Nodes 102 that create sub-queries may further limit to whom thesub-queries (and/or the responses to the sub-queries) are visible. Thus,certain information may be made accessible only to the users to whom theinformation is directly applicable, thereby avoiding informationoverload. This also prevents erroneous responses from being propagatedfurther up the tree. However, the full extent of the tree and thetimeframe within which a response to the original query can be expectedis constantly available to the originating node. Thus, the originatingnode can solicit status updates from any users who currently haveownership of the query (or an associated sub-query).

The server may also store the tree, so that the same users can beconsulted in the future if a similar query is generated. Such aknowledge base may facilitate quicker response to future queries, aswell as provide data for statistical analyses of the response process(e.g., detection of anomalies and development of improvements).

Involvement of the server may also facilitate identification of the bestmethods (e.g., email, text message, etc.) and/or times (e.g., after 5:00PM, not on weekends) by which to contact specific users who are added asnodes. For instance, the server can record which methods and/or timesgenerate the quickest response and use these methods and/or times asdefaults when the users are added as nodes for future queries. Theserver may also have access to users' calendar applications, which wouldallow the method 200 to bypass users who may be unavailable within therequired timeframe (e.g., on vacation or in a meeting).

Although the method 200 describes certain actions as being taken by theusers associated with the nodes 102, in alternative embodiments, theseactions may be taken automatically (i.e., without user intervention orassistance) by computing devices operated by the users. For instance, auser's computing device may execute a program that automatically scansthe computing device for requested information or automatically forwardsqueries to other users.

FIG. 3 is a high-level block diagram of query resolution method that isimplemented using a general purpose computing device 300. In oneembodiment, a general purpose computing device 300 comprises a processor302, a memory 304, a query resolution module 305 and variousinput/output (I/O) devices 306 such as a display, a keyboard, a mouse, astylus, a wireless network access card, and the like.

In one embodiment, at least one I/O device is a storage device (e.g., adisk drive, an optical disk drive, a floppy disk drive, a path selectiontool, and/or a test pattern generation tool). It should be understoodthat the query resolution module 305 can be implemented as a physicaldevice or subsystem that is coupled to a processor through acommunication channel.

Alternatively, the query resolution module 305 can be represented by oneor more software applications (or even a combination of software andhardware, e.g., using Application Specific Integrated Circuits (ASIC)),where the software is loaded from a storage medium (e.g., I/O devices306) and operated by the processor 302 in the memory 304 of the generalpurpose computing device 300. Thus, in one embodiment, the queryresolution module 305 for generating flow-directed collaborativecommunications, as described herein with reference to the precedingFigures, can be stored on a non-transitory computer readable storagemedium (e.g., RAM, magnetic or optical drive or diskette, and the like).

It should be noted that although not explicitly specified, one or moresteps of the methods described herein may include a storing, displayingand/or outputting step as required for a particular application. Inother words, any data, records, fields, and/or intermediate resultsdiscussed in the methods can be stored, displayed, and/or outputted toanother device as required for a particular application. Furthermore,steps or blocks in the accompanying Figures that recite a determiningoperation or involve a decision, do not necessarily require that bothbranches of the determining operation be practiced. In other words, oneof the branches of the determining operation can be deemed as anoptional step.

While the foregoing is directed to embodiments of the present invention,other and further embodiments of the invention may be devised withoutdeparting from the basic scope thereof. Various embodiments presentedherein, or portions thereof, may be combined to create furtherembodiments. Furthermore, terms such as top, side, bottom, front, back,and the like are relative or positional terms and are used with respectto the exemplary embodiments illustrated in the figures, and as suchthese terms may be interchangeable.

What is claimed is:
 1. Apparatus for resolving a query received from afirst node in a network, the apparatus comprising: a processor locatedat a second node in the network; and a computer readable storage mediumcontaining an executable program that, when executed by the processor,causes the processor to perform steps comprising: accepting, by thesecond node, ownership of the query from the first node; receiving, bythe second node, an identification of a third node in the network,wherein the identification is received from a user of the second nodeand the user of the second node believes that a user of the third nodehas information necessary to resolve at least part of the query; andtransferring, by the second node, ownership of the at least part of thequery to the third node, wherein the accepting, the receiving, and thetransferring dynamically generates a data structure that traces apropagation of the query, and the data structure is accessible to anorigin of the query.
 2. The apparatus of claim 1, wherein the datastructure comprises a plurality of nodes including the first node, thesecond node, and the third node, the plurality of nodes is arranged in ahierarchy that illustrates the propagation.
 3. The apparatus of claim 1,wherein the steps further comprise: accepting, by the second node,ownership of a first response from the third node, wherein the firstresponse contains information responsive to the at least a part of thequery; and transferring, by the second node, ownership of a secondresponse to the first node, wherein the second response includes atleast some of the information responsive to the at least a part of thequery.
 4. The apparatus of claim 3, wherein the steps further comprise,prior to transferring ownership of the second response: reviewing, bythe second node, the first response; and generating the second responsein accordance with the reviewing.
 5. The apparatus of claim 4, whereinthe reviewing comprises: aggregating the first response with informationreceived by the second node from a fourth node.
 6. The apparatus ofclaim 4, wherein the steps further comprise: closing, by the secondnode, wherein the closing renders the second node inactive in the datastructure.
 7. The apparatus of claim 3, wherein the steps furthercomprise: receiving, by the second node prior to receiving the firstresponse, a deadline from the third node, wherein the deadline providesa timeframe within which the third node expects to provide the firstresponse.
 8. The apparatus of claim 1, wherein the query is subject to arestriction.
 9. The apparatus of claim 8, wherein the restrictioncomprises a deadline by which the first node requires a response to thequery.
 10. The apparatus of claim 8, wherein the restriction comprises alimit on with whom the query can be shared.
 11. The apparatus of claim8, wherein the restriction comprises a constraint on a form of aresponse to the query.
 12. The apparatus of claim 8, wherein the atleast a part of the query that is transferred to the third node is alsosubject to the restriction.
 13. The apparatus of claim 1, wherein thesteps further comprise: delivering, by the second node, a deadline tothe first node, wherein the deadline provides a timeframe within whichthe second node expects to provide a response to the query.
 14. Theapparatus of claim 13, wherein the deadline accounts for any furtherdeadlines by which the second node expects to receive a response to theat least part of the query.
 15. The apparatus of claim 14, wherein thedeadline and the further deadlines sum together to satisfy an originaldeadline by which the first node requests satisfaction of the query. 16.The apparatus of claim 11, wherein the deadline is alterable by theorigin of the query.
 17. The apparatus of claim 1, wherein datastructure is alterable by the origin of the query.
 18. The apparatus ofclaim 1, wherein the steps further comprise: imposing, by the secondnode, a restriction on the query.
 19. The apparatus of claim 1, whereinthe data structure is stored once the query is resolved.
 20. A computerreadable storage device containing an executable program for resolving aquery received from a first node in a network, where the programperforms steps of: accepting, by a second node in the network, ownershipof the query from the first node; receiving, by the second node, anidentification of a third node in the network, wherein theidentification is received from a user of the second node and the userof the second node believes that a user of the third node hasinformation necessary to resolve at least part of the query; andtransferring, by the second node, ownership of the at least part of thequery to the third node, wherein the accepting, the receiving, and thetransferring dynamically generates a data structure that traces apropagation of the query, and the data structure is accessible to anorigin of the query.